🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

Codex review: needs changes before merge. Reviewed August 24, 2026, 5:14 AM ET / 09:14 UTC.

ClawSweeper review

What this changes

The PR scans bounded Grok CLI completed-turn logs for actual token usage, estimates xAI list-price cost, and keeps OpenCodex xAI records out of the Grok subscription row without request-time credential provenance.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

⚠️ Needs maintainer review before merge - 3 items remain

Keep open: after a remote Grok probe fails, the PR publishes the local fallback but its new Grok projection returns nil without a remote snapshot. Existing menu-card and cost-history consumers intentionally suppress stored provider-derived snapshots, so local Grok usage disappears precisely when the fallback is needed.

Priority: P2
Reviewed head: 48e110528b1f750df895217a78c4b02b4f93dc93

Review scores

Verification

Live Verification

Command: swift run CodexBarCLI --help

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.23.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.23.0.tgz

Assertions:

• FAIL expect_output: --json-output

How this fits together

CodexBar turns provider probes and local logs into token-cost snapshots used by the menu card, cost-history chart, and Usage & Spend dashboard. Grok uniquely has a local CLI-log fallback when its remote billing probe is unavailable.

flowchart LR
A[Grok remote probe] --> B{Remote snapshot available?}
C[Grok CLI session logs] --> D[Bounded local scanner]
B -->|Yes| E[Usage and cost snapshot]
B -->|No| F[Published local fallback]
D --> F
E --> G[Menu card and cost history]
F --> G
E --> H[Usage and Spend dashboard]
F --> H

Before merge

• Restore the published fallback for Grok menu consumers (P1) - When the remote Grok snapshot is cleared after a failed probe, this returns nil. The menu card and history submenu intentionally suppress stored snapshots for provider-derived sources, so the local snapshot published by the fallback scan never reaches them. Fall back to that current-config Grok publication and add a consumer regression.
• Resolve merge risk (P1) - A routine remote auth or network failure can hide otherwise readable local Grok usage from the menu card and cost-history chart.
• Complete next step (P2) - The blocking defect is a small, mechanical Grok fallback repair with clear source and test seams.

Findings

• [P1] Restore the published fallback for Grok menu consumers — Sources/CodexBar/UsageStore+TokenCost.swift:477-480

@clawsweeper automerge

Special instructions:
Restore the scoped Grok publication fallback and add regressions for menu-card and cost-history visibility after remote probe failure; do not edit release-owned CHANGELOG.md.

Both automated findings are addressed, plus the review's other checklist items. The inline comments were left against 09cf7edb0, which no longer exists — the branch has since been rebased onto 27c7f334e and the head is now 03e5a25dc, so I'm summarising here rather than replying in a stale diff.

P1 — Preserve the Grok fallback on repeated probe failures

Fixed in 923193ec0, Sources/CodexBar/UsageStore+Refresh.swift. The guard had been hoisted into the if provider == .grok, publication == nil condition, so a Grok failure with a publication fell through to the generic else if tokenCostRequiresProviderSnapshot { clearTokenSnapshot } branch. Grok now owns its branch outright and can never reach the clear:

if provider == .grok {
    if self.tokenSnapshotPublicationForCurrentProviderConfig(for: provider) == nil {
        Task { @MainActor [weak self] in
            await self?.scanAndPublishGrokLocalTokenSnapshot(...)
        }
    }
} else if Self.tokenCostRequiresProviderSnapshot(provider) {
    self.clearTokenSnapshot(for: provider)
}

Regression coverage is in missing remote snapshot scans and publishes local tokens then clears empty data. Per the review's request it now drives two consecutive failing refreshes (03e5a25dc) rather than one — which matters here, because the first failure is what publishes through the fallback scan and only the second arrives with a publication in place, i.e. the failure that used to wipe the row. Both iterations assert the row still reads 77 tokens and that no redundant rescan ran.

P2 — Refresh pricing before scanning Grok sessions

Correct, and thank you — this was a genuine gap and not one the local tests would have surfaced. refreshPricingIfAllowed is gated to Codex and Claude, and Grok never reaches it at all because its snapshot comes from the provider probe rather than CostUsageFetcher.loadTokenSnapshot. On a machine with Codex or Claude also enabled the shared cache is already populated, so the failure is invisible there; enable only Grok and the catalog never appears and the Cost row shows tokens with no money, permanently.

Fixed in 744677e68. The Grok scan paths now request ModelsDevPricingPipeline.refreshIfNeeded through a summarizeRequestingPricingRefresh wrapper, called from all four scan sites (GrokStatusProbe, both branches in GrokProviderDescriptor, and UsageStore.scanAndPublishGrokLocalTokenSnapshot). It is detached rather than awaited, matching how the Codex and Claude paths already treat it — pricing availability must not delay or fail a local scan — and it is safe to call repeatedly, since it returns immediately unless the cache is stale and serialises through its own coordinator. summarize itself stays synchronous and side-effect free.

Note the inline comment still points at GrokLocalSessionScanner.swift:662; that line is the unchanged pricing lookup, and the fix is upstream of it in the new wrapper, so the anchor looks live even though it is addressed.

Coverage: absent models dev cache requests a background refresh, stale models dev cache requests a background refresh, and fresh models dev cache skips the background refresh. All three assert whether a refresh was requested through an injected transport — no test touches the network.

Real-session evidence

CODEXBAR_LIVE_GROK_CATALOG_PROOF=1 swift test --filter GrokXAISpendCatalogTests, against real local Grok CLI sessions, through the shipped code path:

catalog_source=grok
today_tokens=5043749
last_30_days_tokens=52696354
today_cost_usd=3.3471699999999993
window_cost_usd=49.353424
cost_provenance=listPriceEstimate
history_days=365
priced_days=4
token_days=4
daily_buckets=4
available_sources=grok

The same corpus on main reports 653K tokens and no cost. history_days=365 shows the requested window is honoured (it was pinned to 30). priced_days == token_days shows no day was silently left unpriced. The gated proof was extended in e3cd3b9ce to print cost, provenance and priced-day coverage, since tokens alone cannot evidence the half of this change that is about money.

Those figures were cross-checked against an independent reimplementation of the pricing formula over the same logs; the two agree to the cent.

Merge risk / branch state

Rebased onto current main (27c7f334e); the branch reports clean. Full suite on the head: 77/77 groups, 922 selections, 0 failures. swiftformat --lint and swiftlint --strict clean. Upstream CI green on the previous head including all three Linux builds.

One thing deliberately left undone: no CHANGELOG.md entry. 0.54.1 was finalized and there is no open Unreleased section, so I did not invent a version heading — happy to add one wherever you prefer.

Both new findings addressed at 44d79a95a.

P1 — Do not map every xAI log record to the Grok subscription

Agreed, and taken as specified rather than argued down. Routing on the prefix alone is right for the case that motivated this — traffic authenticated with the user's Grok account, which is what makes it consume SuperGrok quota — but it silently folds an API-key user's pay-as-you-go xAI spend into the subscription row. CodexBar already models the developer platform as its own xai provider precisely to keep those apart, so the old behaviour crossed a boundary the app deliberately maintains.

The usage log carries no per-record credential evidence; I checked every field emitted for xai rows (requestId, timestamp, provider, model, requestedModel, resolvedModel, usage, usageStatus, status, routeDecision, …) and there is nothing about auth, account or key. The signal that does exist is ~/.opencodex/config.json, which records authMode per provider.

So attribution now requires positive OAuth evidence:

• xai routes to .subscription(.grok) only when its configured authMode is OAuth. Anything else returns .tokenOnly — the spend is real, it just belongs to no tracked subscription — rather than .unknown, which would read as "unrecognised provider".
• Fail closed. A missing or malformed config, a providers block without xai, or an entry without authMode all count as no evidence and keep the records off the Grok row.
• OpenCodexRouteDispatcher stays a pure function. The set of OAuth-backed provider ids is threaded in from the caller (OpenCodexUsageFanOut → SpendDashboardSource), so the routing site never touches the filesystem and every existing caller and test that does not care about auth keeps working.
• The gate applies only to xai. openai, kimi-coding, deepseek and opencode-go are untouched — changing them would be an unreviewed behaviour change for other providers — and a test pins that they ignore xAI auth state entirely.

Coverage: xai OAuth config routes to Grok, xai non OAuth config stays token only (parameterised over several non-OAuth values), xai routing fails closed without readable complete OAuth config, non xai subscription routes ignore xai auth state, plus fan-out cases proving the same entries land on the Grok row under an OAuth config and are absent under an API-key one. No test reads the developer's real ~/.opencodex; the home directory is injected.

docs/grok.md no longer claims this path cannot distinguish OAuth from API-key traffic, because it now can.

P2 — Republish the Grok snapshot after a missing catalog refreshes

I looked at this closely and am deliberately not adding a republish path. Reasoning, so you can overrule it if you disagree:

The refresh is fire-and-forget, so the scan that requests it returns whatever the cache currently holds — that part is accurate. But the parse cache stores parsed turns, not prices, so aggregation and pricing re-run on every summarize. The next Grok scan therefore prices against the refreshed catalog with no extra machinery, bounding the unpriced window to a single refresh cycle. That is the same behaviour Codex and Claude already have: refreshPricingIfAllowed dispatches into Task.detached and their current scan does not wait for it either.

The alternative — plumbing a completion signal back across the actor boundary into the @MainActor publication path — buys one refresh cycle of latency on first run, at the cost of a new cross-actor completion path in code that publishes user-visible spend. That trade looked disproportionate, and inconsistent with how the two established providers behave. I have recorded the reasoning as a comment at the call site rather than leaving it implicit, so the next reader does not have to re-derive it.

Happy to build it if you would rather have it.

Evidence

The attribution itself only becomes visible in the app: SpendDashboardSource.mergingOpenCodexInputs is what merges the fan-out into provider rows, and the CLI's cost command reports OpenCodex as its own source rather than routing it, so terminal output cannot show this path. The figures below are read off the freshly packaged build running against real local data, on a machine whose ~/.opencodex/config.json has "xai": { "authMode": "oauth" }; screenshots of both panes follow.

The two halves stay distinguishable in the UI, which makes the attribution legible rather than something you have to take on trust: the CLI goes through the responses API so its SKU is grok-4.6-build, while OpenCodex's records resolve to the bare grok-4.6 / grok-4.5 / grok-4.3. Both sit under the Grok provider.

Independently recomputing the same corpus agrees to the cent on both halves: 54,121,501 tokens / $50.52 for the CLI logs, and $166.25 across 1,520 OpenCodex xai records. The CLI half is reproducible by anyone on their own machine through the gated proof test (CODEXBAR_LIVE_GROK_CATALOG_PROOF=1), whose output is in the PR body.

The negative direction — API-key traffic staying off the Grok row — is covered by tests rather than a screenshot, since demonstrating it live would mean rewriting the machine's OpenCodex config.

State

Full suite on 44d79a95a: 77/77 groups, 922 selections, 0 failures. swiftformat --lint and swiftlint --strict clean. Rebased on 27c7f334e.

Addressed both current findings in 211e1977d and resolved the two review threads.

• P1 / historical xAI attribution: removed current-config-based xAI → Grok routing. usage.jsonl has no request-time credential provenance, so xAI records now remain token-only until the producer can persist that evidence. Removed the config reader/plumbing and added dispatcher/fan-out regressions.
• P2 / first pricing publication: when no models.dev artifact exists, the first Grok scan now awaits the initial best-effort refresh attempt before summarizing. A successful refresh prices the first returned snapshot; stale catalogs still price immediately and refresh in the background. Added a regression that writes the catalog during refresh and asserts the first summary is priced.
• Updated the PR title/body and docs/grok.md so they no longer claim OpenCodex xAI traffic is merged into the Grok subscription row.

Validation on the exact pushed head:

• focused Grok/OpenCodex suites: 32 tests passed
• make check: passed
• make test: 922 selections, 77/77 groups, 0 failed groups, 0 retries
• branch is based on current main (27c7f334e) and the merge-tree is clean

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Heads-up: #3136 just landed on main (with a regenerated parser hash and an updated compatiblePredecessorParserHashes list in CostUsageStoreTests), which is what flipped this back to conflicting. Since this branch shares the OpenCodex aggregator/pricing surface, a rebase onto latest main is the safe path — after resolving, re-run ./Scripts/regenerate-codex-parser-hash.sh and update the exact-list assertion in CostUsageStoreTests if the hash changes. Happy to merge once CI is green.

Rebased onto latest main (a639fdf0398cf6a3d142673028bdcbed6db850e5) and force-pushed exact head 16a2737a32435b8c7480054cda6feebda9e6aed1.

• Preserved Price OpenCodex usage once per entry and stop per-entry catalog/overlay reloads #3136’s optimized OpenCodex aggregation path (resolved Models.dev catalog/custom overlay once, priced once per entry, then memoized by day/hour) and layered the xAI bare-model qualification before pricing on top.
• Regenerated the parser hash: 64c5844b8ea170a6.
• Added main’s cfd84d13ad7d4cfa as a compatible predecessor and updated the exact-list assertion in CostUsageStoreTests.
• Current-head make check passed: parser/provider/package gates current, SwiftFormat 0/1994, SwiftLint 0 violations in 1993 files.
• Full make test passed on the source-identical pre-final-docs-rebase tree: 930 selections, 78/78 groups, 0 failed groups, 0 retries, 0 timeouts. The final upstream delta changed only CHANGELOG.md.
• Branch is 0 behind / 12 ahead and git diff --check is clean.

CI for the new exact head is now running.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Final exact-head status for 16a2737a32435b8c7480054cda6feebda9e6aed1:

• Rebased on current main (a639fdf0398cf6a3d142673028bdcbed6db850e5): 0 behind / 12 ahead; GitHub reports MERGEABLE / CLEAN.
• GitHub CI is fully green: path gate, lint, Linux x64, Linux ARM64, Linux musl, both macOS test shards, aggregate gate, and GitGuardian.
• Local gates are green: current-head make check; 930 selections across 78/78 groups with 0 failures/retries/timeouts on the source-identical pre-final-docs-rebase tree.
• Parser hash is current at 64c5844b8ea170a6; main’s cfd84d13ad7d4cfa is retained as a compatible predecessor with the exact-list assertion updated.
• ClawSweeper reviewed this exact SHA with Findings: None, proof: sufficient, and status: ready for maintainer look; both review threads are resolved.

The requested #3136 rebase/compatibility work is complete, and the owner’s stated CI-green merge condition is satisfied.

Rebased onto current main (c9e7f4df556d914e4652e21fcb30ee9f3845a0b2) and force-pushed exact head 48e110528b1f750df895217a78c4b02b4f93dc93.

• Moved the Grok entry from the now-released 0.55.0 section into 0.55.1 — Unreleased and removed the duplicate Usage & Spend heading.
• Current-head make check passed; parser hash remains current at 64c5844b8ea170a6, SwiftFormat is 0/1994, and SwiftLint reports 0 violations in 1993 files.
• The rebase delta from prior green/reviewed head 16a2737a3 touches only CHANGELOG.md, appcast.xml, and version.env; Sources, Tests, Scripts, Package.swift, and Makefile are unchanged.
• Branch is 0 behind / 13 ahead, git diff --check is clean, and the merge-tree is conflict-free.

Exact-head CI is now running.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.